1. Field of the Invention
The disclosed methods and systems related generally to securing resources and privileges on a computer, and more particularly to controlling access to resources and controlling privileges on a per-process basis.
2. Description of Related Art
A user logs on to a computer locally by giving his user name and password to the operating system (“OS”). The operating system then creates a logon session and an access token for that user. The access token includes a unique identifier, known as a security ID (“SID”) for the logged-on user, the list of privileges the user has or the user's groups have, and a list of all the groups that the user, as identified by his/her unique SID, belongs to. Note that each group is also identified by a unique SID. For each process that is created during the logon session, the OS assigns a copy of the original access token to that process. An example of a process token is shown in FIG. 1.
A user's membership in different groups determines what securable objects, such as a file, process, event, or anything else having a security descriptor, the user is able to access, presuming the object allows members of that group access. Thus, if access to a particular object, such as a file, is limited to only members of a group with SID 54321, and a user is not a member of that group, the user is not able to access that object. Similarly, a user's privileges are limited to those identified in the access token.
Whenever a process tries to access a securable object, the OS performs an access check. The operating system compares the token of the process to the access control list (“ACL”) of the object. An access control list is a list of security protections that applies to an object. An entry in an ACL is known as an access control entry (“ACE”). An ACE contains a set of access rights, such as read/write, etc., and a SID that identifies a group and/or user for whom the rights are allowed, denied, or audited. If a SID in the process token is in the ACL of the object, and within the ACE of that SID, rights are set to “allow”, then the process associated with the process token is able to access the object. Otherwise, the process is denied access to the object. Access to the object may also be denied, even if the process token contains a SID that is in the object's ACL if, for example, within the ACE of that SID, rights are set to deny. Also, some privileges instruct the operating system to bypass an object's ACL. Under such a security arrangement, each process created by the operating system in response to a given process's request therefore has the same token as the requesting process, and thus shares the same access to securable objects and privileges.
However, situations may arise where, in order to perform a required task, a user needs access to secured objects and/or privileges that are outside the scope of his current group membership and/or privileges listed in his access token. One solution to this problem is to make the user a member of a group that has expanded access and/or privileges, such as the Administrators group in a Windows-brand OS. This solution may have unintended consequences, as the user gains not only the needed access and/or privilege(s), but further access and other privileges as well. Making the user a member of the Administrators group enables him to access the particular needed object, but may also enable him to install unauthorized applications, perform unauthorized modifications to the configuration of their computer, and so on. Potentially even more important, users with elevated privileges and access are more vulnerable to viruses, trojans, malware, etc. Thus, a means of granting only needed access and/or privileges is desirable.
In WINDOWS® a Group Policy Object (GPO) is a collection or grouping of configuration settings that are applied to computer users and/or computers/systems automatically and/or remotely. Group Policy is a MICROSOFT® implementation of the general concept of policy-based management, which is a computer management model. One potential implementation of a group policy system is described in U.S. Pat. No. 6,466,932. By applying the configuration settings to the computers/systems, a system administrator or other entity may define and/or set the behavior and/or “appearance”/configuration of the computers/users. Accordingly, a GPO is generally configured by a system administrator or other high-level administrator, and as an object, a GPO can be associated with a hierarchical grouping known as a “container.” A container may be a domain, a site, an organization unit (OU), or other association of computers/systems/users. In some example instances, a GPO may define script options, security options, software-installation options, folder-redirection options, software-maintenance options, and other configuration options.
Each GPO has a list that controls whether the GPO's settings are applied to given users, groups, and/or computers. An entity that is on the list has the GPO's settings applied to it. An entity not on the list does not, at least in response to that GPO. The use of groups, as opposed to user- or computer-identities, as the criterion on which the settings-application decision is made may be referred to as GPO-level filtering. Accordingly, GPO-level filtering allows a system administrator or another to specify whether a GPO is applied or denied to users/computers. The GPO is thus applied in its entirety, or denied in its entirety, to a user/computer/system.
In a MICROSOFT® WINDOWS® implementation, GPOs are populated with settings by a Group Policy Object Editor (GPOE). Settings are applied on client computers by corresponding extensions, called Client-Side Extensions (CSEs). There is a documented extension model that MICROSOFT® provides for software vendors to extend these systems and, by doing so, provide new functionality within the WINDOWS® Group Policy architecture.